Ce n’est pas la première fois que la SNCF passe par les services d’Amazon, en 2018 déjà elle y avait basculé 60 % de ses applications. Lors d’une conférence de presse, Arnaud Monier – directeur technologie chez e.Voyageurs SNCF, filiale de SNCF Voyageurs rassemblant les « forces digitales client » – justifie le choix d’AWS, comme le rapporte La Revue du Digital.
« Financièrement, le business case était positif […] Nous avons fait le choix d’AWS, c’est un choix d’ingénierie. Quand nous avons regardé le profil de risque et les garanties de services, en toute sincérité, nous avons été convaincus. Le ratio entre coût et bénéfice était en faveur d’AWS », explique-t-il.
Qu’en est-il du risque d’être bloqué sur des technologies Amazon ? « Nous avons identifié le risque de l’adhérence aux technologies d’AWS. Nous ne sommes pas tout à fait AWS "locké" mais c’est un risque que nous avions identifié dès le départ […] On regarde à chaque fois si un service existe chez un autre opérateur Cloud, peut-être sous un autre nom, ou s’il s’agit d’un service totalement propriétaire. Si c’est totalement propriétaire, on va expérimenter, et on va se poser la question de mettre une couche de généricité », ajoute-t-il. De quoi échauffer les esprits alors que les questions de souveraineté et de cloud de confiance sont dans toutes les têtes.
Commentaires (36)
#1
Je ne comprends pas que des entreprises publiques ne soient pas forcées de privilégier des solutions nationales et/ou européennes. Ca devrait être une obligation légale.
Parce que si de gros acteurs publiques ne font pas cet effort, il est certains qu’il sera difficile de voir émerger des acteurs conséquents en Europe. A un moment il faut mettre de l’action sur les mots…
#2
+1 Furanku
#3
Je pense que comme ils le disent, le ration Coût/bénéfice est plus intéressant. C’est une entreprise à capitaux publics, mais qui tente de gagner de l’argent.
)… quoi que, quand on voit déjà le prix des billets…
Il faut bien compenser le cout des avantages de certains (pas taper c’est dredi
(Je suis totalement d’accord avec vous, je le précise…)
#4
Sur l’adhérence avec le fournisseur, le problème est épineux. Aller dans un cloud public n’est avantageux que si les applications utilisent “nativement” les services cloud du fournisseur, comme par exemple les services de provisionnement et de déploiement. Or si vous voulez garder la possibilité de déployer de façon indépendante du fournisseur, il faut en général monter une usine à gaz pour déployer vos applis, ce qui fait perdre en agilité et augmente les coûts, ce qui au final diminue fortement l’intérêt d’aller dans le cloud. En résumé : pour se défaire du “lock-in vendor” (adhérence), il faut perdre une partie du bénéfice d’aller dans le cloud et augmenter les coûts alors que la réduction des coûts est souvent vendu (à tort) comme argument de passage au cloud.
Je n’arrête pas de dire chez moi : la clé, c’est l’interopérabilité. Normalement ça fait partie des objectifs de Gaia-X, mais bon…
#4.1
Non, ca a de nombreux avantages notamment en utilisant des technologies qui désamorcent le vendor locking avec par exemple kubernetes et sa déclinaison possible que nous avons en place: AKS/EKS/OnPrem. La techno est indépendante du cloudeur, mais le cloudeur s’occupe d’une partie pas intéressante le déploiement socle.
C’est accélérateur en terme de maintenance et d’appropriation, réduit les couts sur le volume de compétences complexes (exemple, avoir des intervenants compétents sur kube c’est pas simple).
J’ai fait des transitions IBM-cloud vers AWS et selon les technos que tu retient la transition se fait en quelques mois.
#4.2
C’est vrai… EKS peut aider (à condition que plusieurs fournisseurs offrent ce service, mais c’est le cas pour AWS/GCP/Azure, donc tout va bien). Quant aux pics d’activité, c’est une justification fréquente. C’est souvent une bonne idée, mais pas systématiquement. Il faut bien calculer son coup (coût), car aller dans le cloud peut aussi imposer des mesures de sécurité supplémentaires, surtout depuis le RGPD (ex : hyperviseurs dédiés, qui coûtent un bras). J’ai déjà vu des “business case positifs” s’avérer de moins bonnes affaires que prévu.
#5
J’aurai moins de scrupules à évaluer et choisir l’offre des concurrents à la SNCF désormais, ça marche dans les deux sens
#6
Concernant l’enfermement proprio, c’est pas facile et coûteux de l’éviter. Plus le temps passe, et plus des détails d’implémentation spécifiques à un fournisseur vont s’accumuler, ce qui va représenter au final un coût de bascule important (en concurrence avec du dev de fonctionnalités par ex).
(commentaire moins bien écrit que celui de janiko au dessus)
#7
Et c’est que la face visible de la news… Vous ne pouvez pas imaginer ce que se passe en interne a cause de ça…
#8
Et après, les politocards en quête de voix pour renouveler leurs CDD viendront pleurer qu’il faut de la « souveraineté numérique »…
#9
“« Financièrement, le business case était positif […] Nous avons fait le choix d’AWS, c’est un choix d’ingénierie. Quand nous avons regardé le profil de risque et les garanties de services, en toute sincérité, nous avons été convaincus. Le ratio entre coût et bénéfice était en faveur d’AWS », explique-t-il.”
Genre on va croire que ceux qui prennent ce genre de décisions sont les mêmes que ceux qui utiliseront la plateforme au quotidien…
Et au passage, ils choisissent d’engraisser le seul des 3 providers américains qui est aussi spécialisé dans le transport de marchandises.
#10
Peux-tu nous en dire plus ?
#10.1
Evitons xD Ça se trouve je dirais un truc que je ne devrais pas et ça me retombera dessus.
Apres il y a toujours le classique des migrations vers le cloud que veut dire toujours moins de serveurs en interne. Moins de serveurs en interne = espace physique libéré qui doit être revalorisée d’une manière ou d’une autre et etc
#11
Combien de commentateurs ont été lire l’article en lien où e.Voyageurs SNCF justifie ses choix ?
Le choix du cloud chez eux est lié aux pics de trafic, comme par exemple les ventes de noël, pas à la mode du cloud sans raison particulière. J’avais pensé à ça avant de lire l’article, mais ils confirment “, là où nous avons 2 à 3 serveurs en temps normal, il en faut entre 17 et 25 en période de pointe”
Avec de telles variations, je veux bien croire que ça puisse être rentable.
Et d’autres raisons sont aussi données.
#11.1
Sur un périmètre kube de voyageur (je ne donne pas plus de détails) j’ai des clusters kube qui scalent de 2 noeuds à 32 noeuds selon des périodes :P le paiement à la minute c’est énormément d’économies.
Là on a fait des campagnes finops pour redimensionner les gabarits en place. Forcer les bonnes valeurs de demande de ressources. On a eu des gains de 60% de facture (rien que sur de l’opti cloud).
Cette opti on ne peut pas l’avoir “on prem” car on doit de toute facon payer tout les serveurs. Là le cloud rajoute l’option de se débarrasser de facture machine. MAIS, ca rajoute aussi le fait que les projets demandent plus de machines à tour de bras là où avant onprem ils étaient limités :P
#12
Mais c’est déjà ce que tout le monde fait. Concurrence entre train, voiture, vélo, pieds, avion… Et maintenant entre compagnies ferroviaires (Thello). Bon, j’attends qu’on vienne me parler de TER ou de Transilien pour qu’on rigole un peu ;)
En interne, beaucoup ont déjà “adoré” le passage à Office 365 sans aucune formation des utilisateurs, l’obligation de tout mettre sur Sharepoint, fini le stockage de docs en interne…
#13
Pour moi c’est une gestion “financière” des problèmes : En cas de panne, ils s’imaginent qu’ils vont compenser en touchant de l’argent de AWS… c’est ptet vrai d’ailleurs.
Bref….. encore une belle démonstration du coté visionnaire de nos dirigeants. D’ici 3 ans les USA pourront bloquer tous les trains d’un simple bouton. Après Alsthom j’aurais imaginé qu’ils auraient au moins appris 2⁄3 infos sur leurs “alliés”. Apparemment c’était encore trop demander.
Ou alors c’est que le chèque est plus gros de l’autre coté de l’atlantique.
#13.1
Le pire c’est qu’on sait déjà que les USA font de l’espionnage industriel, dont les Appels d’Offres, grace/en partie à leurs GAFAM.
Comme dit au-dessus, tant bien même le cloud serait rentable, il serait quand même de bon ton d’en selectionner un FR/Européen, pas ça qui manque. Et pour ceux qui disent “beuh, c’est moins bien, y’a moins de fonctions”…si personne ne les prends jamais, ils ne risquent pas d’avoir les fonds de se développer…
#14
Peut-etre qu’enfin les horaires de la SNCF s’afficheront aussi bien, et aussi vite que sur les sites … Suisses.
#15
Les Suisses sont réputés pour leur ponctualité mais non pour leur vivacité.
#15.1
Je ne parles pas des horaires des chemins de fer suisse.
Je disait qu’il vaut mieux consulter les horaires de la SNCF sur les applis suisses que sur les applis de la SNCF. Car les horaires SNCF affichées par les applis suisses sont mieux mis à jour que sur les applis de la SNCF.
#15.2
ah ok!
#16
Pouvez-vous m’indiquer quelles “solutions nationales et/ou européennes” fournissent des solutions équivalentes à celles qui vont être utilisées par les équipes de la SNCF ?
Non seulement nous ne connaissons pas les solutions qui vont être utilisées, donc impossible de dire si un équivalent français/européen existe. Mais surtout le delta de qualité de service entre OVH/Scaleway/d’autres acteurs plus mineurs et AWS est… élevée.
Quand c’est moins bien et plus cher, pourquoi passer par ces solutions ? A moins de vouloir saborder son activité et s’assurer que les clients aillent ailleurs car tu factures un moins bon service plus cher que la concurrence.
#16.1
Est-ce qu’au moins tu les as testés en condition réelle avant de dire que c’est “moins bien et plus cher” ? Cest juste différent, et très souvent moins cher (ça fait longtemps que ce n’est plus le hardware qu’on paie, mais le software au dessus). Et tu prends un français comme Clever Cloud ( par exemple (je ne bosse pas chez eux, c’est pas de la pub… et je n’ai jamais utilisé Scaleway ou le PaaS OVH), ils n’ont pas grand chose à prouver quant à la qualité de service, et ce qu’ils proposent suffit très probablement pour 95% des sites que la SNCF veut passer sur le cloud.
#17
Sur les gabarits cloud, il y a de quoi discuter. Je comprends qu’il y a des économies substantielles à faire sur les réservations, mais des fois les limitations sur les gabarits utilisables à la création entraînaient un surdimensionnement significatif.
J’irai défendre le on-prem en soulignant que ce qui est payé c’est de la capacité globale, qui est subdivisée avec suffisamment de malléabilité pour dimensionner au plus proche des besoins utilisateurs.
C’est pertinent quand l’usage ne bouge pas significativement dans le temps, mais clairement le processus de mise à disposition de VM ne va pas fournir 20 machines à configuration [custom/similaire à l’existant] sous une semaine pour gérer une montée en charge.
#18
Cloud ça ne veut rien dire. Si c’est juste de l’IaaS c’est relativement rapide d’aller ailleurs
#19
L’histoire des gabarits est à remettre dans le contexte de la conteneurisation/kubernetes :) Avec des conteneurs tu peux blinder un serveur plus aisément sans et avoir un meilleur ratio d’utilisation de la VM.
Autant sur une application standard on considère que 15% est un mauvais chiffre, en kubernetes 50% en est un (on vise 70% dans nos chiffres internes, on vois pas mal de 40% avec des mauvaises définitions de requests/limits sur les conteneurs).
Mais le gain de 60°% instantané c’est juste arrêt soir et WE pour le hors prod.
Les changement de gabarits pour correspondre aux bons ratios CPU/RAM c’était entre 15 et 20% en plus.
Mais sinon oui, je suis d’accord pas de différence avec le onprem si tu n’a pas de scalabilité. Sauf … pour l’arrêt soir et WE qui est un argument qui pèse vu que pour le onprem même si arrête tu dois bien payer l’amortissement de la machine physique.
#20
En gros tu échanges un avantage immédiat contre un risque potentiel et une perte de contrôle de l’activité à long terme. C’est l’éternel problème du business.
#21
Quel est le risque potentiel et la perte de contrôle qui sont présents uniquement avec les solutions non françaises/européennes ?
#22
Le rachat à la Alsthom <> GE ou l’espionnage industriel notamment pour le pipotage des appels d’offre et / ou le sabotage des projets qui sont contraire aux intérêts américains (je pense ici aux différences politiques entre les US et l’EU sur , entre autre, les normes en matière de GES).
Plus généralement le renseignement au sens large existe et n’a pas forcément d’objectif précis & immédiat mais est intégré dans une stratégie globale de sape des autres pays.
Il y a aussi le fait que les USA essaient d’imposer l’extraterritorialité de leurs lois notamment via l’utilisation des GAFA via le Cloud Act , sans pour autant accepter la réciprocité envers les lois EU : Ils se donnent ainsi, par exemple, la possibilité de siphonner toutes les données des voyageurs de la SNCF si ils le souhaitent, et ce quelque soit la teneur du contrat entre la SNCF et AWS, et ce sans aucune considération pour la RGPD qui ne s’appliquent pas à eux (puisque les données sont chez AWS qui est à eux).
Or ils ont déjà par le passé montré que pour eux la notion d’allié est toute relative quand il s’agit de jeux de pouvoirs.
Un autre “risque” plus économique reste simplement l’enfermement dans un système (ici AWS) qui implique que l’argent payé par les voyageurs va partir (pour une part) pour payer Amazon aux US, impactant ainsi la balance commerciale globale de la France qui est déjà très déséquilibré depuis les USA. C’est de l’argent qui ira renflouer le compte de Jeff sans être réutilisé dans l’économie locale. Ça me dérange pas trop lorsqu’il s’agit de produits simples que l’on ne produit pas en Europe, c’est plus compliqué lorsqu’il s’agit des données personnelles ou d’une entreprise systémique.
Je ne parle même pas des emplois dans nos contrés.
Enfin il faut faire aussi attention que ce ne soit pas du greenwashing à bon compte, dans le sens où en externalisant son informatique outre-manche la sncf peux ainsi “diminuer” artificiellement les émissions en ne les comptant plus, et comme les USA ne sont pas soumis au même standard que nous… (je vois ça comme une sorte d’évasion fiscale-ges, en quelque sorte).
Alors oui rien ne dit qu’un OVH ou autre serais parfait - nul cloud ne n’est , après tout le cloud n’est rien d’autre que l’ordinateur de quelqu’un autre - et les pannes arriveront quoi qu’il arrive. Mais quand elles arrivent je préfère avoir les données et les machines à coté de chez moi qu’outre-atlantique.
#22.1
Je suis pleinement d’accord avec toi, mais dans les textes étasuniens et leur extraterritorialité, celui qui pose le plus de problème en matière de sureté économique et financière pour une grosse boite comme la SNCF, c’est plus le Patriot Act…
Avec le Patriot Act, pas besoin de juge…
Au moins avec le OnPrem, on a moins de questions de ce genre à traiter. Et pas sur que ça coute plus cher, vu l’explosion du coût du SI de la SNCF depuis qu’elle pratique le tout cloud.
#23
Oui, j’ai testé, en sachant quel était mon besoin réel. Plutôt que de lancer des approximations sans savoir quel est le besoin de l’entreprise concernée.
#23.1
Je suis curieux de savoir lequel tu as testé et pourquoi c’est “moins bien et plus cher”.
De mon côté, ce n’est pas juste des “approximations”, je travaille au quotidien à migrer des applications d’une grosse entreprise sur du cloud (un des 3 clouds américains), et ce que je vois, c’est que sur une centaine d’applications, y’en a seulement 4-5 qui ne seraient pas rentré sur un PaaS français si on enlève celles où les teams déploient du K8S pour tout et n’importe quoi sans en avoir besoin (un front end, un backend, hop, un cluster K8S).
Alors je veux bien croire que la SNCF est différente, mais si ils migrent des applications On Prem, ça m’étonnerait beaucoup que ça soit si différent que ça.
#24
Le RGPD (car le règlement).
Les États-Unis d’Amérique n’ont aucun allié, par définition : ils n’ont soit que des pays asservis à leurs intérêts (après les avoir ratatinés ou non), soit des ennemis à détruire (physiquement, pas juste symboliquement). Parce que dans leur idée, il en va de la continuation même de leur existence en tant que pays (qu’ils placent au-dessus de tout).
Les États-Unis d’Amérique sont de fait en guerre permanente contre tout le reste de l’Univers et le resteront jusqu’à la mort du dernier de leurs ressortissants. C’est leur histoire qui veut ça, à cause des conditions même de la naissance de leur pays, et ils n’ont jamais quitté cet état d’esprit où absolument tout ce qui est autour d’eux est rien de moins qu’une menace mortelle pour leur existence. Et comme il est absolument hors de question que l’existence des États-Unis d’Amérique puisse prendre fin (et ce, pour n’importe quelle raison que ce soit, aussi bien humaine que naturelle), ils ne voient pas d’autre choix que d’aller éliminer purement et simplement tout ce qui pourrait (mais même si le risque réel est négligeable, voire inexistant) la mettre en danger.
#25
Je suis moins radical que toi, mais j’avoue qu’il y a cette idée. C’est aussi pour ça que ce fut très longtemps l’un des pays les plus moteurs d’innovation de la planète.
A mon sens c’est aussi pour ça qu’ils s’effondreront avant tout le monde: Ils sont structurellement incapable de choisir une voie qui les ferait décroître, donc il mangeront le mur à pleine vitesse.
Le vrai souci est qu’il y a de forte chance qu’ils nous entraînent avec eux.
#26
C’est en effet schématisé à l’extrême, mais c’est ce qui ressort en filigrane tout le temps, avec eux (et de manière bien plus explicite auprès des trumpistes les plus enragés).
Ça a déjà commencé, ça. Mais ils ne sont pas les seuls responsables du désastre en cours, seulement la tête de file.